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Executive summary 


IT-relaterade arkitektroller i Sverige 2012 


Syftet med detta dokument år att uppdatera den tidigare utgivna ”Arkitektroller 
inom IT i Sverige 2007” med mer information samt modernisera innehållet. 
Rollbeskrivningarna år nu tydligare relaterade mot IASA:s internationella 
definitioner för att båttre fungera för organisationer som befinner sig på en 
internationell arena. 


Arbetet med dokumentet har resulterat i definitionen av totalt fyra 
kompetensroller som beskriver den typ av arbete som utförs samt en funktion 
för att samordna arkitekturarbete. 


Kompetensrollerna som definieras år: 

e  Verksamhetsarkitekt 

e Lösningsarkitekt 

е  Mjukvaruarkitekt 

е Infrastrukturarkitekt - Nytillkommen i denna utgåva 
Funktionen som definieras år: 


е Enterprisearkitekturfunktion - Omdefinierad till funktion i denna 
utgåva 


Utöver dessa specifika roller och funktion så definieras ett antal förmågor som 
år önskvärda för personer med IT-relaterade arkitektroller oavsett vilken roll 
de agerar inom. 


Materialet innehåller åven en modell för hur samverkan typiskt sker mellan 
olika arkitektroller och funktioner i förhållande till organisationens 
uppbyggnad. 
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1 Introduktion 


1.1 Bakgrund 


IASA gav 2007 ut dokumentet ”Arkitektroller inom IT i Sverige 2007” i en 
ansats att skapa en enad bild av vilka olika arkitektroller inom IT som finns 
oavsett företag eller organisation. Detta dokument har varit uppskattat och har 
fungerat på ett normgivande sått för både företag och myndigheter sedan dess. 
2012 års uppdatering återbesöker dessa arkitektroller och uppdaterar dem 
utifrån de föråndringar som skett sedan 2007. Sedan 2007 har åven IASA 
International kommit ut med rolldefinitioner och utbildningsmaterial knutet till 
dessa definitioner, vilket detta material relaterar till. 


I detta dokument har beskrivningarna av de olika rollerna nyanserats, 
grånsdragningen mellan befintliga roller har tydliggjorts, det har tillkommit en 
roll och angrånsande roller har tagits med för diskussion. 


1.2 Syfte 


Detta dokument har flera syften: 


е Skapa en rik beskrivning av olika arkitektroller oberoende av 
organisation och utbildning. Detta genom att presentera roller snarare ån 
titlar eller befattningar (som varierar mycket mellan olika organisationer 
och utbildningar). Rollerna definieras genom beskrivningar, leverabler och 
ansvarsområden. Det år fullt möjligt att en och samma person axlar flera 
roller inom sin organisation. Dessa beskrivningar hjålper både 
organisationen att strukturera sitt arkitekturarbete och ger individen 
möjlighet att jämföra sin egen kompetens med de rekommenderade 
rollerna. 


• ТудПдаге relatera till internationella roller. Detta dokument relaterar 
tydligare mot IASA Internationals definierade roller. Syftet med detta år att 
materialet skall fungera åven i de internationella organisationer som 
verkar i Sverige, samt att de olika certifieringar som IASA erbjuder baseras 
på de internationella definitionerna. 


е  Beskriva rollernas inbördes relation. Detta för att tydliggöra skillnader 
och likheter mellan olika roller. 


е Säkerställa ett heltäckande arkitekturarbete. Genom att presentera och 
synliggöra vilka arkitektroller och ansvarsområden som bör finnas i en 
organisation år vår förhoppning att kunna bidra till ett arkitekturarbete 
som år heltåckande vad gåller verksamhets- och teknikutveckling. 


е Vara ett hjälpmedel vid rekrytering. Detta dokument år ett hjälpmedel 
både för individen och rekryterande organisationer för att matcha 
efterfrågad kompetens med erbjuden kompetens. 


е Fördjupa och förtydliga. Dokumentet syftar även till att fördjupa och 
förtydliga de roller som år definierade sedan tidigare. 


1.3 Målgrupper 
De tånkta målgrupperna för att låsa detta dokument år: 


е Arkitekter – För att kunna identifiera den egna kompetensen och relatera 
den till de rekommenderade rollerna 


е Arbetsgivare — För att kunna bygga upp еп väl fungerande organisation 
med arkitekter och för att få en förståelse för vilka roller som behövs samt 
hur dessa förhåller sig till varandra. 


е Rekryterare – För att ge både egna rekryterare och rekryteringsföretag en 
tydlig bild över de olika arkitektrollerna och de krav som stålls på dessa för 
att göra mer lyckade rekryteringar. 


e Övriga målgrupper - Angränsande roller, exempelvis IT-chef, уд med 
flera som vill skapa sig en bild av vilka olika typer av IT-arkitekter som 
finns. 


1.4 Vad år IT-arkitektur? 


IASA Internationals definition av IT-arkitektur år ”the art or science of designing 
and delivering valuable technology strategies” som kan översättas till ”förmågan 
att designa och leverera vårdefulla teknikstrategier”. 


En IT-arkitekt definieras av IASA International som ”Technology Strategist for 
the business” som kan översättas till ”teknikstrateg för verksamheten”. 


Fokus för en arkitekt år alltså att leverera verksamhetsnytta i form av beslut 
och strategier inom IT som ger verksamheten mest nytta för investerade 
resurser. 


Detta innebår att arkitektur inte så mycket består av de modeller och artefakter 
som tas fram under arkitekturarbetet, utan snarare de beslut som ligger bakom 
varför man valt just dessa och varför man valt en viss lösning till ett visst behov. 
Bakom dessa beslut kan det ligga övervåganden om tillgånglig kompetens, 
kalendertid, likviditet, långsiktig vinst, driftskostnad, trender på marknaden, 
tekniktrender, möjlighet till vidareutveckling, konkurrenters lösningsval med 
mera. 


2 Omfattning och avgrånsning 


För att du som låsare av detta dokument skall kunna relatera till informationen 
i dokumentet så redovisas hår omfattningen av innehållet, definitioner av 
grånsdragningen mellan rollerna samt vilka antaganden som gjorts. 


е  Kompetensroller vs titlar. Dokumentet beskriver enbart olika 
kompetensroller och hur dessa förhåller sig till varandra. Detta innebår 
att förutom att en individ kan аха en kompetensroll så kan en och 
samma roll delas av flera individer och en individ kan också ha flera 
roller. 


Ytterligare ett skål att beskriva roller snarare ån titlar år den flora av 
titlar och befattningar som finns i både svenska och internationella 
organisationer, samt att strukturen på dessa inte alltid går att föråndra 
inom den svenska delen av organisationen. Vi ger dock i slutet av 
dokumentet några exempel på titlar och befattningar som år vanliga i 
svenska företag för att illustrera hur det kan se ut. 


е Positionering. De olika rollerna beskrivs i dokumentet i två olika skalor 
dår den ena avser specialisering på skalan verksamhet kontra teknik 
och den andra graden av omfattning på skalan helhet kontra detaljer: 


о Verksamhet-teknik. Självklart år allt arbete som bedrivs inom 
en organisation verksamhetsstödjande, åven de mer 
teknikintensiva delarna. Skalan skall mer ge en vink om var 
fokus vanligen ligger för respektive arkitektroll, dår verksamhet 
betecknar organisationens huvudsakliga syfte och teknik 
betecknar tekniska lösningar för en specifik uppgift. 


Samtliga arkitektroller inom IASA:s verksamhetsområde, oavsett 
specialisering, inbegriper en viss kunskap om både verksamhet 
och teknik längs denna skala. Detta innebär att vissa roller 
definieras som angrånsande roller istållet för IT-relaterade 
arkitektroller, t ex affårsarkitekt på verksamhetssidan och 
hårdvaruarkitekt på tekniksidan. 


о Helhet-detaljer. De flesta roller innehåller en mix av dessa två 
element. Skalan reflekterar var tyngdpunkten för arbetet ligger. 


е  Rollbeskrivningar. Rollerna beskrivs utifrån följande skala: 


o Beskrivande vs normerande. Hår ligger tyngdpunkter på att 
skapa normerande roller utifrån erfarenheter från flera stora 
svenska organisationer. 


3.1 Översikt av roller 


IASA rekommenderar i 2012 års utgåva av IT-relaterade arkitektroller i Sverige 
följande kompetensroller: 


е Verksamhetsarkitekt 
е  Lösningsarkitekt 
e  Mjukvaruarkitekt 
е  Infrastrukturarkitekt 
Samt enterprisearkitekturfunktionen (EA-funktionen) 


Dessa roller och funktion beskrivs i mer detalj långre fram i detta dokument. 


3.1.1 Positionering 


En arkitekts fokus definieras av var de befinner sig på skalan verksamhet- 
teknik och på skalan helhet-detaljer. Det finns inga knivskarpa grånser mellan 
rollerna och beroende på organisation och personliga egenskaper så flyter de 
ihop med varandra. Detta år i grunden något positivt då det minskar risken för 
att viktiga frågor hamnar mellan stolarna. Pilarna i illustrationen nedan visar 
hur respektive roll har en förmåga att röra sig mellan verksamhet och teknik 
samt mellan helhet och detaljer. 


EA- 
funktion 


Helhet 

Verksamhets- Lösnings- 
е6 arkitekt 
Infrastruktur- 
arkitekt 
Mjukvaru- 
arkitekt 
Detalj 


Verksamhet Teknik 


3.1.2 Samverkan mellan roller 


För att lyckas med arkitekturarbete krävs en samverkan mellan samtliga 


definierade roller, samt att arkitekten interagerar med den verksamhet denne 
verkar inom. Olika roller har sitt fokus och sin huvudsakliga hemvist i olika 


delar av organisationen. 


Huvudsaklig hemvist 


Verksamhetsarkitekt I organisationens huvudsakliga verksamhet 


nåra utveckling av processer och 
informationshantering 


Lösningsarkitekt Mellan verksamheten och de teknikstöd 
som stöttar verksamheten, samt flöden 
mellan de mjukvaror som kråvs för att ge 


verksamheten maximal nytta 


Mjukvaruarkitekt Nåra de applikationer som anvånds av 
verksamheten 


Infrastrukturarkitekt Såkerståller att organisationen har rått 
infrastruktur för verksamhetens behov av 


applikationsstöd, kommunikation, 
datalagring och såkerhet 


Enterprisearkitekturfunktion Sammanhållande funktion för 


(EA-Funktion) arkitekturarbetet inom organisationen med 
fokus på helhetssyn 


I exemplet i bilden nedan illustreras hur de olika rollerna samspelar. 


Enterprise EA-funktion 


Verksamhetsområden Applikationsstöd ICT- 
infrastruktur 


Försåljning Försåljning $ М Datahall су 
сл. ИА. si 


-- 
s.” 
-- 


- 
= 
--<-77 
ат) 
-- 


Verksamhets- = Mi Infra- 
е jukvaru- ў 
реА arkitekt $, arkitekt O ши 


Verksamhet Teknik 


3.2 Gemensamt för alla arkitekter 


Även om detta dokument primårt syftar till att beskriva de olika 
arkitektrollerna så år det viktigt att påpeka att oavsett arkitektroll så finns det 
fler kånnetecken som förenar rollerna ån som skiljer dem åt. 


Få personer kan leva upp till allt som listas nedan men som arkitekt bör du 
kånna igen dig i merparten av punkterna. Listan år grupperad enligt IASA:s 5 
arkitekturella grundpelare. (Se 3.3.6 Relation till IASA Internationals roller samt 
Appendix Å - Kopplingar mot IASA Internationals arkitekturella grundpelare för 
mer information.) 


е Teknikstrategi för verksamheten (Business Technology Strategy): 


= Har en förmåga att förstå och relatera till organisationens syfte, 
mål och strategier 


= Sätter mål och medel i relation till varandra. Är det rimligt att nå 
upp till målet i förhållande till insatsen som krävs? Finns det 


10 


något alternativ som nåstan ger samma nytta men med lågre 
insats? 


Har erfarenhet från den verksamhet som organisationen 
bedriver och den kontext organisationen verkar inom 


е IT-miljö (IT Environment): 


Har egen erfarenhet från flera olika perspektiv (exempelvis 
projektledare, förvaltare, analytiker och utvecklare) och har 
senior erfarenhet från flera områden 


e Design (Design): 


Har en god förmåga att beskriva, modellera, visualisera och 
analysera åven komplexa strukturer, skeenden och samband 


Har en adekvat teknisk kunskap för sin roll 


Lyfter blicken och ser utanför det egna ansvarsområdet. 
Såkerståller att organisationen inte bara gör saker rått - utan 
åven gör rått saker 


Ser till helheten och kan samtidigt dyka ner i detalj inom den 
egna rollens område 


Arbetar strukturerat och har en analytisk förmåga 


е Kvalitetsattribut (Quality Attributes): 


Har förmågan att balansera olika aspekter mot varandra, så som 
flexibilitet mot förvaltningsbarhet, prestanda mot kostnad och 
tånkta anvåndningsmönster etc. 


е Social förmåga (Human Dynamics): 


Kan konsten att kommunicera - ауеп med personer inom helt 
andra kompetensområden 


Har en god förståelse för, och förmågan att orientera sig inom, 
organisationens politiska landskap och kan anpassa sitt budskap 
efter målgrupp 


Nåtverkar med andra både inom och utanför den egna 
organisationen 


Har god social kompetens 
Har ett öppet sinne och år mottaglig för nya influenser och idéer 


Är serviceinriktad och tillgänglig - som arkitekt finns du till för 
organisationen och inte tvårtom 


Har ett naturligt engagemang och drivkraft 


3.3 Roll- och funktionsbeskrivningar 


3.3.1 Verksamhetsarkitekt 


3.3.1.1 


3.3.1.2 


3.3.1.3 


Definition 


En verksamhetsarkitekt arbetar med verksamhetens processer, information 
och system i samverkan. 


En verksamhetsarkitekts fråmsta målsåttning år att hjålpa organisationen att 
möta nya omvårldskrav. Exempelvis fokuserar vissa verksamheter på snabba 
och tvåra föråndringar, medan andra fokuserar på stabilitet eller att hantera en 
krympande marknad. 


Typiska frågor för en verksamhetsarkitekt år att beskriva och analysera 
verksamhetsprocesser, hur dessa kan förbåttras, hur informationen hanteras, 
om informationskvaliteten år hög och om det finns systemstöd som stöttar 
verksamheten på rått sått. 


Verksamhetsarkitekten ser till att den ena handen vet vad den andra gör. Hon 
eller han påminner ledningen om tidigare tagna beslut samt visar på 
konsekvenser vid tånkta föråndringar. 


En verksamhetsarkitekt bör vara väl bevandrad inom verksamhetens kontext – 
trender, händelser i omvärlden samt vad kollegor och konkurrenter i 
verksamhetsområdet håller på med. 


Ansvarsområden 


Verksamhetsarkitekten ansvarar för att visualisera företagets verksamhet med 
hjälp av olika modeller, både nuläges- och målbeskrivningar. 


Han eller hon säkerställer sambandet mellan informationsflöden och 
verksamhetsprocesser samt att information och processer är organiserade ur 
verksamhetens perspektiv. Dessutom ansvarar verksamhetsarkitekten ofta för 
att kraven på IT-stöd utgår från verksamhetens behov. 


En viktig uppgift för en verksamhetsarkitekt är att se till att startade initiativ är 
hanterbart små, har rätt avgränsning och kan återanvändas till hög grad. Denne 
hjälper dessutom till med att inom projekt och andra initiativ lyfta blicken från 
aktuell (och kortsiktig) leverans till helhetsperspektiv för att nå 
arkitekturmålen. 


Aktiviteter med typiska leverabler 


En verksamhetsarkitekt jobbar mycket med visualiseringar och beskrivningar. 
Detta gäller framtagning av målarkitektur- och nulägesbeskrivningar på den 
detaljerade nivån men även på en högre abstraktionsnivå såsom design och 
visualisering av processer (alltså även med processförbättring eller förslag på 
sådan) samt information och sammanhang. 


I verksamheter med högre grad av förändring jobbar verksamhetsarkitekten 
med flera parallella scenarier för att beskriva önskad målbild och väger initiativ 
mot samtliga av dessa. 
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3.3.1.4 


3.3.1.5 


3.3.1.6 


Verksamhetsarkitekten levererar exempelvis stadsplan, processkartor, 
scenariodiagram, tjånstekartor, begreppsmodeller, informationsmodeller och 
förmågekartor. 


Grundkompetens 
Verksamhetsarkitekten har följande grundkompetens: 


е Förstår verksamheten och vilka krav som ställs på den samt kan 
översätta detta till grova planer för IT-lösningar 


е Кап skapa verksamhetsmodeller tillsammans med organisationens 
verksamhetsspecialister, fråmst hur processer och information och dess 
koppling till system ser ut 


е Har djup förståelse Юг organisationens huvudsyfte och den domän där 
organisationen verkar. Ar insatt i det politiska låget inom organisationen 
och har goda ledaregenskaper 


е Har djupa kunskaper inom process-, begrepps- och 
informationsmodellering samt kravhantering 


е Наг kunskap om systemlandskap och dess komplexitet samt vad 
systemlandskapet ger för möjligheter och begrånsningar i olika scenarier 


Plats på kartan (verksamhet-teknik) 


Verksamhetsarkitekten har fråmst verksamhets- och nyttoperspektiv. Få 
organisationer har verksamhetsarkitekter organisatoriskt tillhörande en 
operativ verksamhet. Vanligtvis tillhör en verksamhetsarkitekt en stab (för 
kvalitet, standarder, arbetsmetoder, verksamhetsutveckling med mera) eller 
arbetar någonstans i IT-organisationen. 


Interagerar med 


Verksamhetsarkitekten interagerar med ledning, affårsutvecklare, 
affårsarkitekter och verksamhetsrepresentanter på olika nivåer samt 
samplanerar stadsplanen med lösningsarkitekter. 


En verksamhetsarkitekt stödjer lösningsarkitekten vid analys och kravanalys på 
olika IT-lösningar. 


Verksamhetsarkitekten sitter ofta med i IT-ledningsforum eller bereder 
underlag till sådant. Hon eller han sitter med i projekt och styrgrupper dår 
viktiga initiativ tas och utveckling sker. I våsentliga och kritiska arbeten tar 
verksamhetsarkitekten stållning och arkitekturansvar. 


3.3.2 Lösningsarkitekt 


3.3.2.1 


Definition 


En lösningsarkitekt arbetar med att planera realiseringen av IT-lösningar 
baserat på verksamhetens behovsbild och med förutsåttningar från existerande 
IT-tjånster i organisationen. 


Lösningsarkitekten har fokus på att se till att återanvåndning av funktionalitet 
sker samt att såkerstålla att de företagsövergripande arkitekturprinciperna och 
riktlinjer kring standarder följs i den tekniska arkitekturen. En produkt eller 
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lösning står sållan ensam, utan år snarare oftast en del av en helhetslösning i en 
organisations arkitektur. Därför år den specifika lösningens gränssnitt mot 
omvärlden av största vikt för lösningsarkitekten. Lösningsarkitekten kan ofta 
sägas fokusera på lösningar som spänner över flera olika system. 


En lösningsarkitekt har djup kunskap om de betydande kvalitetsattributen och 
kan balansera dem mot de funktionella kraven och bereda underlag för 
nödvåndiga prioriteringar och kompromisser. 


Lösningsarkitektens intresseområde år både att såkerstålla det aktuella 
projektets framgång och möjligheten att förvalta lösningen samt att se till att 
företagets övergripande strategier följs. 


3.3.2.2 Ansvarsområden 


Lösningsarkitekten ansvarar för att IT-lösningar realiseras (ofta genom projekt) 
på ett korrekt sätt i enligt med verksamhetens krav och i förhållande till andra 
IT-lösningar samt att lösningen kan leva vidare under en lång tid. 
Lösningsarkitekten formulerar och säkerställer ofta även de icke-funktionella 
kraven. 


Lösningsarkitekten ansvarar tillsammans med verksamhetsarkitekten för att 
säkerställa att de tekniska lösningarna utgår från och integreras med 
verksamhetsarkitekturen. Vid teknikval spelar lösningsarkitekten en viktig roll, 
inte bara för att ge ett funktionellt perspektiv utan även ett förvaltnings- och 
styrningsperspektiv. 


3.3.2.3 Aktiviteter med typiska leverabler 
Lösningsarkitektens typiska aktiviteter och leverabler är följande: 


е  Såkerståller att lösningens kvalitetsegenskaper (såsom prestanda, 
skalbarhet, robusthet, förvaltningsbarhet och flexibilitet) adresseras och 
vägs mot funktionella krav 


е бег Шан det finns en spårbarhet mellan verksamhetsbehov, krav och 
lösning. 


е Exempel på artefakter som lösningsarkitekten tar fram år 
processmodeller, integrationsstrategier, scenariobeskrivningar och 
informationsmodeller. 


е  Fokuserar på helheten - inte bara att systemet gör saker rått utan även 
att systemet gör rått saker 


е Genomförande av arkitekturgranskningar 
3.3.2.4 Grundkompetens 
Lösningsarkitekten har följande grundkompetens: 


е Förmåga att omsätta verksamhetsarkitekturen till hållbara tekniska 
lösningar 


е Сода modelleringskunskaper 


е Djup teknisk kompetens 
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3.3.2.5 


3.3.2.6 


е Djup och bredd - övergripande kunskap inom IT och teknik, men även 
specialiseringar såsom inom infrastruktur, datamodellering eller 
tjånsteorientering 


е Förmåga till helhetssyn 


е  Bedömningar av realiseringsalternativ (Iönsamhetsbedömningar), 
exempelvis om man skall köpa eller bygga sjålv 


е God ledarskapsförmåga då lösningsarkitekten sällan år direkt chef för de 
personer som år inblandade i projekten 


е God kommunikationsförmåga för att kunna diskutera frågeställningar 
både med tekniska specialister och personer utan teknikkunskap 


е Сода kunskaper i utvecklingsprocessen och dess steg. Kunskap om 
utvecklingsverktyg och annan teknik så som databas, ramverk, 
tredjepartsprodukter med mera 


Plats på kartan (verksamhet-teknik) 
Lösningsarkitekten agerar mitt emellan verksamhet och teknik. 
Interagerar med 


Lösningsarkitekten interagerar framförallt med verksamhetsarkitekter och 
utvecklingsteam (mjukvaruarkitekt) men åven med 
enterprisearkitekturfunktion och infrastrukturarkitekten. 


Beroende på lösningsarkitektens placering på skalan verksamhet-teknik kan 
han också anta rollerna verksamhetsarkitekt respektive mjukvaruarkitekt. 


3.3.3 Mjukvaruarkitekt 


3.3.3.1 


Definition 
En mjukvaruarkitekt arbetar med att strukturera och designa mjukvaror så att 


de uppfyller både funktionella krav och de olika arkitekturella kvalitetskrav 
som stålls på systemen. 


Beroende på mjukvaruarkitektens huvudsakliga inriktning så varierar 
huvuduppgifterna något, som följer: 


е Verkar i huvudsak inom ett enskilt projekt med uppgift att fokusera ра 
projektets framgång med hånsyn tagen till verksamhetens uppsatta 
strategier och riktlinjer 


е Таг! huvudsak ansvar för en specifik produkt eller ett specifikt system 
inom en verksamhetsdomån och såkerståller livscykeln för det systemet 
inklusive förvaltning med mera 


Mjukvaruarkitekten arbetar vanligen på en mer detaljerad nivå ån 
lösningsarkitekten, varvid rollen kan ses som en specialisering av 
lösningsarkitektens. 


På den detaljerade nivån ansvarar mjukvaruarkitekten för att realiserade 
komponenter inom t ex ett projekt, både ramverk- och 
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3.3.3.2 


3.3.3.3 


3.3.3.4 


3.3.3.5 


verksamhetskomponenter, kan återanvändas och återföras till Iösnings- 
arkitekturen. 


En mjukvaruarkitekt år ofta en viktig medlem i ett utvecklingsteam med 
detaljerad kunskap om just den produkt eller det system som skall föråndras 
eller utvecklas. Det år också en roll som i större utsträckning ап övriga 
arkitektroller antas snarare ån tilldelas, enligt agila sjålvorganiserande 
principer. 


Ansvarsområden 


Mjukvaruarkitekten ansvarar för att mjukvaran hålls ihop och att den år i det 
skick den bör vara relaterat till sin position i livscykeln. I detta ingår att 
säkerställa att valda mönster används, samtidigt som det år av vikt att kunna 
jåmka olika behov inom mjukvaran. 


Ytterligare ett ansvarsområde år att såkerstålla att mjukvaran år möjlig att 
installera, uppgradera, förvalta och дуегуаКа samt att rått kompetens Юг detta 
finns. 


Ett annat område för en mjukvaruarkitekt år att agera så kallad technical lead. I 
detta ingår att utöva mentorskap för utvecklare i utvecklingsteamen. 


Aktiviteter med typiska leverabler 


Mjukvaruarkitekten fungerar som expert för en eller flera mjukvaror i 
diskussion med lösningsarkitekten runt nya lösningar. 


Exempel på artefakter som mjukvaruarkitekten tar fram år 
scenariobeskrivningar, datamodeller, processmodeller, rekommendationer för 
designmönster samt beskrivning av tånkt livscykel och förvaltning. 


Grundkompetens 

Mjukvaruarkitekten har följande grundkompetens: 
е Сода kunskaper i modellering 
е Design- och konstruktionsmönster 


е Djup teknisk kunskap, särskilt i de tekniker som används inom 
mjukvaran 


e God kunskap inom programvaruutveckling 


е Förståelse för den verksamhet och det tekniska sammanhang där 
mjukvaran finns och verkar 


е Ofta specialist på någon av de ledande plattformarna, .NET eller Java, eller 
på någon specifik produkt 


Plats på kartan (verksamhet-teknik) 


Mjukvaruarkitekten har på skalan verksamhet-teknik övervikt mot teknik. 
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3.3.3.6 


3.3.4 
3.3.4.1 


3.3.4.2 


3.3.4.3 


Interagerar med 


Mjukvaruarkitekten interagerar med lösningsarkitekter, utvecklingsteam, 
kravanalytiker, slutanvåndare, projektledare, produktågare och testledare med 
flera. 


Infrastrukturarkitekt 


Definition 


En infrastrukturarkitekt arbetar med att strukturera, dokumentera och föreslå 
den infrastruktur som matchar organisationens behov. 


En infrastrukturarkitekt blir inblandad i de flesta IT-relaterade projekt men 
även för löpande drift och förbättringar. Infrastrukturarkitektur år en 
leverantörsfunktion i större utsträckning ап övriga typer av arkitektur. 


Med infrastruktur menar vi hårdvara, nätverk, tekniska plattformar och verktyg 
för systemövervakning med mera. Men den innefattar även en del mjukvara 
som blivit såpass standardiserad eller dold att den fungerar som en del av 
verksamhetens infrastruktur, såsom operativsystem, e-postserver, 
säkerhetslösningar etc. Infrastrukturarkitekten ansvarar för hur dessa 
infrastrukturkomponenter påverkar de olika kvalitetsegenskaperna (icke- 
funktionella kraven). 


Infrastrukturarkitekten designar och optimerar de möjliggörande IT- 
infrastrukturerna. 


Ansvarsområden 


En infrastrukturarkitekt är ansvarig för infrastrukturens arkitekturella vyer, 
vilket innebär en konceptualisering av infrastrukturens komponenter för 

arkitekturens olika intressenter. Detta medför också att infrastrukturen blir 
tillgänglig för lösningsarkitekturen och kan bidra till enterprisearkitekturen. 


Infrastrukturarkitekten är också ansvarig för hur olika mjukvara överlämnas, 
driftsätts och övervakas i driftorganisationen, t ex enligt processer såsom 
ITIL:s. 


En infrastrukturarkitekt säkerställer att organisationen har rätt IT- 
infrastruktur för verksamhetens syfte, samt att infrastrukturen hålls 
uppdaterad i en lagom takt för organisationens behov. Vidare säkerställer 
infrastrukturarkitekten också att tillämpliga styrmodeller finns uppsatta, samt 
tillhandahåller dokumentation av infrastrukturen. 


Aktiviteter med typiska leverabler 
Infrastrukturarkitektens typiska aktiviteter och leverabler är följande: 


е Deltagande vid uppstart av projekt för att säkerställa infrastruktur- 
lösningar som ligger i linje med utvecklingsplaner, både som stöttning för 
projekt och för att tidigt få insikt i nyttan med lösningen 


е  Kapacitetsberåkning med modeller för skalning 
е Bedömning av driftsalternativ (såsom egen hall, cloud och virtualisering 


med mera) beroende på kvalitetsattribut 


16 


е Arbete med upphandlingar inom området ICT(informations- och 
kommunikationsteknik) 


е Kostnadsberåkningar för olika lösningar och visa hur olika 
kvalitetsattribut påverkas av krav, kostnad och utav varandra 


е Typiska leverabler år fysiska vyer av lösningar, nåtverkskartor, proof of 
concepts, övervakning, tekniska riktlinjer (exempelvis runt autentisering, 
databas, applikationsservrar och servicebussar) och styrmodeller runt 
infrastruktur etc. 


3.3.4.4 Grundkompetens 
Infrastrukturarkitekten har följande grundkompetens: 
e God teknisk kunskap 


е Kunskap om hur kvalitetsattribut påverkas av olika 
infrastrukturlösningar 


е Förståelse för olika behov av infrastruktur inom verksamhetens olika 
delar 


3.3.4.5 Plats på kartan (verksamhet-teknik) 


Infrastrukturarkitekten ligger långt åt det tekniska hållet på skalan 
verksamhet-teknik, men har även verksamhetens behov för sina ögon. 


3.3.4.6 Interagerar med 


Infrastrukturarkitekten interagerar med enterprisearkitekturfunktion för 
långsiktiga mål samt med lösningsarkitekter, mjukvaruarkitekter, 
nätverkstekniker och hårdvaruexperter med flera. 


3.3.5 Enterprisearkitekturfunktionen 
3.3.5.1 Definition 


Enterprisearkitekturfunktionen (EA-funktionen) ansvarar för att såkerstålla det 
holistiska arkitekturperspektivet i den gemensamma enterprisearkitekturen för 
att leverera vårde till organisationen och för de beslut, riktlinjer, mallar, 
verktyg, metoder, principer och styrmodeller som anvånds för att bedriva 
arkitekturarbetet. 


En enterprisearkitektur år ingen isolerad företeelse. I sjålva verket uppstår en 
vål exekverande enterprisearkitektur når samspelet fungerar mellan de roller 
som ansvarar för att utveckla och förvalta arkitekturen, а у 5 verksamhets-, 
lösnings- och infrastrukturarkitekter och de roller som äger och använder 
arkitekturen. EA-funktionen tillhandahåller stödjande strukturer för ett bra 
samspel och interaktion dels mellan de roller vi definierar i detta dokument 
men också med övriga arkitektroller och intressenter. 


Beroende på verksamhetens typ och organisationens storlek kan ansvaret för 
enterprisearkitekturen ligga hos en för åndamålet avsedd grupp eller skötas 
genom ett samarbete mellan de olika arkitekterna i organisationen. 
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3.3.5.2 


3.3.5.3 


3.3.5.4 


3.3.5.5 


3.3.5.6 


Ansvarsområden 


Syftet med EA-funktionen år att såkerstålla att IT totalt sett stödjer 
organisationens strategiska affår och att IT-stödet år byggt på ett sådant sått att 
det år förberett för framtida föråndringar i affårsmodeller och nya 
verksamhetskrav. EA-funktionen såkerståller att IT-stödet realiseras på ett 
effektivt och långsiktigt hållbart sått. 


EA-funktionen ansvarar för att verksamheten får hög effekt/nytta av sina 
system som helhet, att man har en övergripande strategi för framtida 
funktioner och IT-investeringar samt att verksamhetens IT-arkitektur år 
kostnadseffektiv. EA-funktionen ansvarar för att balansera mål och medel, det 
vill såga att företaget får ut maximal nytta av de pengar som investeras inom IT. 


Aktiviteter med typiska leverabler 


EA-funktionen ansvarar för att det finns en låmplig styrmodell och andra 
strukturer på plats för att utveckla, förvalta, planera och följa upp 
arkitekturarbetet. EA-funktionen uppråttar och förvaltar strukturer för 
samarbete mellan olika slags arkitekter och övriga intressenter - särskilt fokus 
ges till anvåndarna av arkitekturen. 


Ofta åger EA-funktionen strategier på flera områden inom organisationen. Detta 
kan vara alltifrån strategier för tekniska standarder som år viktiga för hela 
företaget till strategier för såkerhet och infrastruktur. En klassisk analogi år att 
jåmföra EA-funktionens arbete med ett stadsbyggnadskontor som ser till att 
alla funktioner i en stad fungerar korrekt och optimalt med hjålp av planering, 
strategier och regler. 


Typiska leverabler år dokumentmallar, strategier, styrmodeller, 
beslutsunderlag och input till olika föråndringsinitiativ med mera. 


Grundkompetens 


Alla arkitekter bidrar till enterprisearkitekturarbetet men styrningen och 
beslutsfattandet i EA-funktionen genomförs ofta av mer erfarna arkitekter. 


Plats på kartan (verksamhet-teknik) 


EA-funktionen spånner över både verksamhet och teknik med fokus på att 
verksamheten skall ha det totala IT-stöd som bäst stödjer verksamhetens syfte. 


Interagerar med 


EA-funktionen interagerar med samtliga arkitektroller samt IT-chefer, ledning 
och övriga beslutsfattare med flera. 


3.3.6 Relation till IASA Internationals roller 


IASA International har en något annorlunda indelning av roller och använder 
lite andra begrepp. Vi finner det nödvändigt att sätta dessa i relation till 
definitionerna i detta dokument, samt att motivera avvikelser. I tabellen nedan 
redovisas de begrepp som används inom IASA International. 
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Begrepp Beskrivning 


Architect Role Motsvarar det IASA Sverige definierar som 
en funktion 


Architect Specialisation Motsvarar det som IASA Sverige definierar 
som kompetensroller. IASA International 
talar mer om specialiseringar. 


Foundation Body of Den förmåga som varje arkitekt behöver 

Knowledge/Foundation besitta, oavsett vilken specialisering 

Pillars (kompetensroll) arkitekten har, se åven 
Appendix A - Kopplingar mot IASA 
Internationals arkitekturella grundpelare. 
Den viktigaste av dessa arkitekturella 
grundpelare år Business Technology 
Strategy, det vill såga förmågan att leverera 
strategiskt vårde till verksamheten. 


Istållet för enskilda rolldefinitioner talar man alltså om olika specialiseringar. 
Dessa år: 


е Business architecture 

e Information architecture 

e Infrastructure architecture 
е Software architecture 


Denna uppdelning illustreras i bilden nedan: 
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Enterprise Architecture 


Software Infrastructure | Information Business 
Architecture Architecture Architecture | Architecture 


Foundation Body of Knowledge 


Design 


Quality Attributes 


IT Environment 


Alla arkitekturella grundpelare gåller alla typer av arkitekter oavsett 
specialisering. Enterprisearkitekten definieras dåremot som en roll, till skillnad 
från specialiseringarna. En enterprisearkitekt behöver övergripande förståelse 
för alla fyra definierade specialiseringar. 


I tabellen nedan redovisas hur IASA Sveriges definitioner förhåller sig till [ASA 
Internationals specialiseringar/roller. 


IASA International IASA Sverige 
Specialisering/roll Kompetensroll/funktion 


Enterprise Architecture Enterprisearkitekturfunktion. Dessa två 
begrepp matchar varandra helt. 


Software Architecture Lösningsarkitekt samt mjukvaruarkitekt. 
Under svenska förhållanden år det 
meningsfullt att dela på denna ganska breda 
definition då det år olika krav som stålls på 
dessa personer 


Infrastructure Architect Infrastrukturarkitekt. Dessa två begrepp 
matchar varandra helt. 


Information Architecture Verksamhetsarkitekt. I Sverige år det 

Business Architecture vanligare att man fokuserar på information i 
kombination med processer och rollen 
verksamhetsarkitekt år vedertagen för detta. 
Specialiseringen enligt IASA International 
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finns dock i Sverige i form av 
informationsarkitekter samt 


processarkitekter. 
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4 Relaterade roller 


Det finns många titlar på arkitekter och nårbeslåktade roller som tangerar 
arkitektområdet. Nedanstående lista år exempel på förekommande roller och 
hur dessa överensstämmer med IASA:s definitioner. Vissa roller år 
angränsande, andra specialiseringar av eller synonymer till IASA:s definitioner. 


e Affårsarkitekt - En affårsarkitekt stödjer organisationens ledning i arbetet 
med att analysera marknaden, definiera önskad position, skapa och 
transformera affårsmodeller, processer och vårdenåtverk så att 
organisationens och teknikens möjligheter utnyttjas lönsamt. 
Affärsarkitekten arbetar nära en organisations ledning och 
affärsutvecklare och tar det huvudsakliga ansvaret för att säkerställa att 
verksamheten har de stödjande strukturer och förmågor som krävs för att 
leverera det som affären kräver. Affärsarkitekten jobbar strategiskt närmre 
affären än verksamhetsarkitekten i samverkan med verksamhetsarkitekter 
och enterprisearkitekturfunktioner. 


е  Anvåndbarhetsarkitekt - En specialisering inom användbarhet, relaterar 
till mjukvaruarkitekt eller lösningsarkitekt 


е — Applikationsarkitekt - Tåcks av mjukvaruarkitektens i roll enligt detta 
dokument 


е Chefsarkitekt - Den person som samordnar och leder organisationens 
arkitekturarbete. Denna person år ofta den som leder 
enterprisearkitekturfunktionen men kan också vara samordnare för ett 
forum utsett till att koordinera arkitekturarbetet. 


e Domånarkitekt - En specialisering inom någon av organisationens 
verksamhetsdomåner. Denna arkitekttyp motsvarar oftast en 
verksamhetsarkitekt. 


е  Informationsarkitekt - En specialisering ау verksamhetsarkitektrollen 
som fokuserar på den delmångd av arkitektarbetet som rör informations- 
hanteringen. Inom det området såkerståller informationsarkitekten 
frågorna både med verksamhetsarkitekten och lösningsarkitekten och 
täcker därigenom spannet från verksamhet till teknik. 


е  Integrationsarkitekt - En lösningsarkitekt med fokus på integrationer 
mellan olika system och med fördjupad kunskap inom integration 


е IT-arkitekt - Generell benämning på IT-relaterade arkitektroller. 


e Lead developer - Motsvarar i vissa sammanhang en mjukvaruarkitekt 
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Processarkitekt - Fokuserar liksom informationsarkitekten ра en 
delmångd av arkitekturarbetet, nåmligen processer. Processarkitekten 
arbetar fram och såkerståller sina resultat tillsammans med både 
verksamhetsarkitekten, affårsarkitekten och lösningsarkitekten för att 
såkerstålla hela spannet från affår och organisation till verksamhet och 
teknik. 


<Produkt>-arkitekt - Med en <produkt>-arkitekt menas exempelvis 
Sharepointarkitekt, Webspherearkitekt etc. Detta år en specialistroll som 
nårmast kan liknas med mjukvaruarkitekten. 


Projektarkitekt - En person som år ansvarig för arkitekturarbetet inom 
ett projekt. Ofta år detta en lösningsarkitekt men kan också vara en annan 
arkitekttyp beroende på projektets syfte. 


Systemarkitekt - Tåcks av mjukvaruarkitektrollen 1 detta dokument 


Såkerhetsarkitekt – En specialisering av lösningsarkitekten med 
fokusering på olika aspekter av såkerhet 


Teknisk projektledare - Driver teknikdelen av ett projekt och kan vid IT- 
relaterade projekt ibland ta rollen som lösningsarkitekt eller 
mjukvaruarkitekt alternativt samarbeta nåra en sådan. 


Testarkitekt - En specialisering av lösningsarkitekten med fokusering på 
att optimera för testbarhet 


5.1 Hur kommer detta leva vidare 


Detta dokument skall revideras med jämna mellanrum. Revisionen skall se över 
rolldefinitionerna, innehåll och exempel samt uppdatera dokumentet med 
hånvisningar till mer låsning. 


5.2 Komplement till materialet 


Detta material kompletteras av en Powerpointpresentation som ger en översikt 
över innehållet. 


Tanken är att bilagor och relaterade dokument kommer att skapas successivt 
med detta material som grund. 


5.3 Definitioner 


Följande definitioner har använts i materialet: 
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Enterprise - Arbetsgruppen har valt att inte översätta enterprise eller 
enterprisearkitektur i enlighet med OpenGroups rekommenderade 
översättningar för arkitekturrelaterade termer. Med enterprise menas 
kombinationen av verksamhetens syfte och dess organisation och 
arbetssätt att uppnå sina syften. Exempel på enterprise är ett företag, en 
stiftelse eller en myndighet. 


EA - Enterprisearkitektur 


IT - Omfattar både verksamhet och teknik. Brygga emellan teknik och 
verksamhet 


Kompetensroll - En samling förmågor och kompetens som har 
grupperats till en roll. Denna roll är skild från titlar och är ofta skild från 
anställningsroll även om de kan sammanfalla. En kompetensroll kan 
verka inom en eller flera domänroller 


Organisation — För att materialet skall fungera både för företag, 
myndigheter och andra verksamheter så används konsekvent ordet 
organisation inom detta dokument och skall läsas som synonym till 
företag etc. beroende på läsarens referens. 


Projekt - I detta dokument har order projekt använts som samlingsnamn 
för program, projekt, förändringsinitiativ, implementering etc. 


Teknik - Har i detta dokument använts liktydigt med IT-relaterad teknik. 
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Verksamhet - De aktiviteter organisationen genomför för att uppnå sina 
syften 


6.1 Projektgrupp 


Tabellen nedan listar deltagarna i projektgruppen som tagit fram det hår 
dokumentet. 


Person Företag 


Anders Larsson Softronic 
Annelie Wiberg IRM 


Eva Kammerfors Cordial 


Jonas Toftefors Centiro, certifierad CITA-P 


Kerstin Jonsson IRM 


Per-Erik Padrön Perago, certifierad CITA-P 


Dessa deltagare har kollektivt personliga erfarenheter från samtliga definierade 
kompetensroller och domånroller. 


Dokumentet godkåndes av IASA:s styrelse för publicering 2012-04-24. 


6.2 Referensgrupp 


Följande personer har deltagit i granskningen av dokumentet och kommit med 
vårdefull information som hjålpt till att utveckla materialet. 


Det år viktigt att påpeka att all granskares åsikter inte år med i dokumentet och 
att respektive granskare inte år medförfattare till materialet. 


Person Organisation 


Christer Berg Dataföreningen Kompetens 
Daniel Lindbom HiQ, certifierad CITA-P 


Kerstin Stenberg Dataföreningen, IT-arkitekturutbildning 


Lajos Farkas LAFA-Data, certifierad CITA-P 


F 
Per-Magnus Skoogh трРеіга, Dataföreningen, agilutbildning 
Peter Tallungs IRM, IASA:s styrelse 
Robert Lagerström KTH 
Fredrik Wahlström Folksam 


6.3 Mer låsning 


Kommentar 


www.iasa.se IASA Sveriges hemsida dår senaste versionen 


av detta dokument finns tillgångligt 


www.iasaglobal.org IASA Internationals hemsida 
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7 Appendix А — Kopplingar mot IASA Internationals 


arkitekturella grundpelare 


Enligt IASA Internationals definition av de arkitekturella grundpelarna och dess 
delområden år samtliga viktiga oavsett arkitektroll. Dock så kan vi se att vissa 
delområden år extra viktiga för några av rollerna. Detta innebär inte att de år 
oviktiga för övriga roller. 


För en detaljerad definition av arkitekturella grundpelare och delområden se 
till exempel följande dokument: 


"СІТА-Р Proficiency and Knowledge Assessment Manual” 
http://www.iasaglobal.org/iasa/Resources.asp 
”Candidate Skills Assessment” 


http://www.iasa.se/wp-content/uploads/2010/12/Candidate-Skills- 
Assessment.rtf 


7.1 Teknikstrategi för verksamheten (Business Technology Strategy) 
Delområde Kompetensroll 
Business fundamentals Verksamhetsarkitekt 


Strategy rationalization and Verksamhetsarkitekt 
development 


Industry analysis Verksamhetsarkitekt 
Business valuation Verksamhetsarkitekt 


Investment prioritization and Verksamhetsarkitekt, lIösningsarkitekt 
planning 


Requirements discovery and Lösningsarkitekt, verksamhetsarkitekt 
constraints analysis 


Compliance Verksamhetsarkitekt 


Business architecture methods Verksamhetsarkitekt, lösningsarkitekt 
and Tools 


Decision support Lösningsarkitekt 
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Knowledge management Verksamhetsarkitekt 


7.2 IT-miljö (IT Environment) 


Delområde 


Technical project management 


Asset management 
Change management 
Infrastructure 
Application development 
Governance 


Testing methods, tools, and 
techniques 


Platforms and frameworks 


7.3 Design (Design) 


Delområde 
Requirements modeling 
Architecture description 
Decomposition and reuse 


Design methodologies and 
processes 


Design patterns and styles 
Design analysis 


Traceability through the 
lifecycle 


Views and viewpoints 


Whole system design 
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Kompetensroll 


Lösningsarkitekt, verksamhetsarkitekt 


Verksamhetsarkitekt, infrastrukturarkitekt 
Verksamhetsarkitekt, lösningsarkitekt 
Infrastrukturarkitekt 

Lösningsarkitekt, mjukvaruarkitekt 
Verksamhetsarkitekt 


Lösningsarkitekt, mjukvaruarkitekt 


Lösningsarkitekt, mjukvaruarkitekt 


Kompetensroll 

Verksamhetsarkitekt, Іӧѕпіпрѕагкіќекі 
Lösningsarkitekt 

Lösningsarkitekt, verksamhetsarkitekt 


Lösningsarkitekt, mjukvaruarkitekt 


Lösningsarkitekt, mjukvaruarkitekt 


Lösningsarkitekt 


Lösningsarkitekt 


Lösningsarkitekt 


Lösningsarkitekt 


7.4 Kvalitetsattribut (Quality Attributes) 


Delområde 

Balancing and optimizing 
Maintainability etc. 
Monitoring and management 
Performance etc. 


Security 


Usability etc. 


Packaging, delivery etc. 


Kompetensroll 

Lösningsarkitekt 

Mjukvaruarkitekt, lösningsarkitekt 
Infrastrukturarkitekt 
Infrastrukturarkitekt, lösningsarkitekt 
Lösningsarkitekt, infrastrukturarkitekt 
Mjukvaruarkitekt, lösningsarkitekt 


Mjukvaruarkitekt, infrastrukturarkitekt 


7.5 Social förmåga (Human Dynamics) 


Denna grundpelare år lika viktig oavsett arkitektroll. 
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